home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1191.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.7 KB  |  54 lines

  1. > Yes, for a single realm.  The problem is that with the Web you are reading
  2. > documents from all over (many possible realms).  Are you going to require
  3. > that the user kinit in a shell window for each document at a different
  4. > site (possibly having to exit the browser each time for line-mode browsers
  5. > with no job control)?
  6.  
  7. I'm not "requiring" it, Kerberos is. How many Kerberos realms you are
  8. known to? I'm known to only 2 (possibly 3). Cross realm authentication
  9. doesn't work yet. I may indeed look at lots of docs at lots of sites
  10. around the net, but I am not known to most of the Kerberi in the world,
  11. and I am certainly not in any way privileged elsewhere in the world.
  12. The reason I (and I suspect most people in the world) want
  13. authenticated WWW is so that privileged folk at a site can read
  14. confidential docs and lock the rest of the world out. When proper
  15. cross-realm authentication is in widespread use, no-one will have to
  16. enter passwords to get a foreign ticket anyway.
  17.  
  18. As to job control, line mode browsers start telnet happily enough, so
  19. they can run kinit the same way.
  20.  
  21. > It would have to be a different protocol  I chose kerberosIV-1 as the name
  22. > of this protocol, another might be kerberosAFS-1, there would also be
  23. > kerberosV-1 and maybe even kerberosIV-2.
  24.  
  25. But it's NOT a different protocol!! AFS Kerberos is the same procotol
  26. as MIT Kerberos. The only difference is in clients which translate
  27. passwords to keys - kinit, kpasswd and login. It just confuses matters
  28. to treat them differently. The easiest solution is a Kerberos client
  29. which understands both, which is invisible to HTTP.
  30.  
  31. > I cannot think of any other reasonable solution with the current
  32. > technology (and I'm not interested in rolling my own).
  33.  
  34. Neither can I. However, I'm trying to be realistic; after 3 years of
  35. looking after a Kerberos authenticated system, I think I know it fairly
  36. well. I don't think you can get round this problem. Any "roll your own"
  37. solution is useless unless everyone ELSE has it!
  38.  
  39. I'd guess that browser writers don't want to put Kerberos functionality
  40. into their software - far easier to just run kinit/klog or the local
  41. X11 ticket manager/password changer. Tyro users see the interface that
  42. they're used to, rather than a line mode "dialog box".
  43.  
  44. Kerberos functionality in plexus is great, but won't be used unless
  45. there are Kerberos aware browsers, so let's not make life difficult for
  46. browser writers by insisting they re-invent wheels. I'd prefer them to
  47. devote their talents to making the Web look nicer.
  48.  
  49. Peter Lister                                    p.lister@cranfield.ac.uk
  50. Computer Centre,
  51. Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
  52. Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875
  53.  
  54.